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Preface 


The GCS Configuration Management Plan is document # 5A in a series 
of documents which fulfill the Radio Technical Commission for Aeronautics 
RTCA/DO-178A guidelines, “Software Considerations in Airborne Systems 
and Equipment Certification”. These documents were prepared under con- 
tract with NASA-Langley Research Center. 

This project consists of two complementary goals. First, to develop soft- 
ware for use in the Research Triangle Institute (RTI) software error studies 
research program sponsored by NASA-Langley Research Center [1]. Sec- 
ond, to use and assess the RTCA/DO-178A guidelines for the Federal Avi- 
ation Administration (FAA). The two goals are complementary in that the 
use of the structured DO-178A guidelines in the development of the software 
will ensure that the test specimens of software have been developed accord- 
ing to the best standards for critical software. The error studies research 
analyses will then be conducted using high quality software specimens. The 
implementations will be subjected to two different software testing environ- 
ments: verification of each implementation according to RTCA/DO-178A 
guidelines and replicated random testing in an n- version configuration. This 
research effort involves the gathering of product and process data from ev- 
ery phase of software development for later analysis. More information on 
the goals of the Guidance and Control Software (GCS) project are available 
in the GCS Plan for Software Aspects of Certification (document #14). 

The series consists of the following documents: 

- GCS Configuration Index Document no. 1 
GCS Development Specification Document no. 2 

- GCS Design Descriptions One for each software implementation. Doc- 
ument no. 8 

- GCS Programmer’s Manual Document no. 4> includes Software De- 
sign Standards, document no. 12. 

- GCS Configuration Management Plan Document no. 5A 

- Software Quality Assurance Plan for GCS Document no. 5B 
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GCS Source Listings One for each software implementation. Docu- 
ment no. 6 

GCS Source Code One for each software implementation. Not avail- 
able on hardcopy. Document no. 1 

GCS Executable Object Code One for each software implementation. 
Not available on hardcopy. Document no. 8 

GCS Support/Development System Configuration Document no. 9 

GCS Accomplishment Summary Document no. 10 

Software Verification Plan for GCS Document no. 11 

Software Requirements Review Description for GCS Document no. 
UA 

GCS System Requirements Document no. 18 

GCS Plan for Software Aspects of Certification Document no. 14 
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1 


Contents 

Preface 

1 Management Methods 1 

2 Documents Under Configuration Management 2 

3 Configuration Procedures ® 

4 Version Numbering Scheme ® 

A Representatives 

List of Tables 

1 Organization and Authorization for Managed Documents . 3 

1 Organization and Authorization for Managed Documents (cont.) 4 


-ill- 



1 Management Methods 

This report describes the methods and tools used for the configuration 
management of the Guidance and Control Softwaxe experiment ( GCS ) 
project-related documents. The use of configuration management tech- 
niques is intended to reduce confusion over multiple versions of the docu- 
ments and to increase traceability of changes throughout the lifetime of the 
various documents. Configuration management for this project will consist 
of defining and using an orderly, structured method of storing, recalling, 
and modifying any document (including software) that is produced. By 
using a configuration management scheme, compliance with the require- 
ments outlined in the RTCA document DO-178A is insured. Configuration 
management also has the advantage of encouraging a uniform method of 
access to all documents* 

To reduce the time, effort, and cost of setting up and using a config- 
uration management scheme, tools that are already available at RTI and 
AIRLAB will be used. Also, the number of people with direct access to 
these documents will be kept to a minimum and the procedure for updating 
documents will be kept as simple as possible. 

The most important configuration tool will be the Code Management 
System (CMS) provided by Digital Equipment Corporation (DEC). CMS 
provides a method of tracking and retrieving versions of documents. CMS 
uses “libraries” that contain all versions of the documents. The operations 
allowed within CMS are as follows: 

Fetch A copy of the file is placed in the current directory, but no changes 
to the file within the library are made. 

Reserve A copy of the file is placed in the current directory. The file is 
marked within the library so that no else may make changes to it 
during this time. The file will later be returned to the library and 
any changes will be made to the library copy. 

Replace A file that has been reserved may be replaced and in doing so, 
an y changes to the file are put into the library for later use. 

Unreserve If a file has been reserved, but no changes were made, the file 
may be unreserved. This will simply remove the restriction on that 
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file within the library, so the original operation becomes very similar 
to a fetch. 

There will be six CMS libraries to hold the documents. There will 
be one library for documents produced by the management team (Doc 
Library) and controlled by the on-site Software Quality Assurance repre- 
sentative (SQA Rep.) and the Configuration Manager (Cfg. Mgr.). There 
will be one library for the GCS specification (Spec Library) and its for- 
mal modifications that will be controlled by the SQA Rep. There will be 
three libraries for the application programmers (Prog Libraries 1-3). Each 
of these libraries will contain all documents produced or modified by the 
programmers including their source code. The programmer libraries will 
be controlled by the SQA Rep. and Cfg. Mgr. Last, there will be a library 
(Test Library) that will contain files of test cases used and test logs gener- 
ated during the Verification procedure. 1 This library will be controlled by 
the on-site SQA representative. Programmers should have private libraries 
to keep their code in during development and module testing. This will 
allow old versions/fixes to be restored if necessary. 

Because of the form of documentation used for some documents, (e.g. 
the design description will be in teamworfc 2 format and the problem re- 
ports are filled out by hand on paper), these documents will be configured 
using hard copies only. Other documents such as the object code can be 
reproduced from the source code, thus do not need to be placed under 
configuration management directly. 

2 Documents Under Configuration 
Management 

Table 1 below contains a list of the documents under configuration manage- 
ment, which libraries contain them, a list of people authorized to request 
copies of the documents, and a list of people authorized to update the 
library. 

1 This explanation may be expanded and more libraries may be added depending on 
the type of tools used for verification. 

2 Team work is a registered trademark of Cadre Technologies Inc. 
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Table 1: Organization and Authorization for Managed Documents 


Document 

Library 

Authorized 

Requesters 

Authorized 

Controllers 

Configuration Index 
(Doc #1) 

Doc 

Mgmt. Team 

SQA Rep. 

GCS Specification 
(Doc. #2) 

Spec 

Mgmt. Team 

SQA Rep. 

Specification 
Modifications 
(part of Doc. #2) 

Spec 

Mgint. Team 

SQA Rep. 

Design Description 
(Doc. #3) 

Hard Copy 

Testers 

SQA Rep. 
Cfg. Mgr. 

Programmers’ Manual 
(Doc. #4) 

Doc 

Mgmt. Team 

SQA Rep. 
Cfg. Mgr. 

Programmer 
Instructions 
(part of Doc. #4) 

Doc 

Mgmt. Team 

SQA Rep. 
Cfg. Mgr. 

Configuration 
Management. Plan 
(Doc. #5A) 

Doc 

Mgmt. Team 

SQA Rep. 
Cfg. Mgr. 

SQA Plan 
(Doc. #5B) 

Doc 

SQA Rep. 

Cfg. Mgr. 

Programmers’ 
Source Listing/Code 
(Doc. #6 and #7) 

Prog 

(1, 2, or 3) 

Testers 

SQA Rep. 
Cfg. Mgr. 

Object Code 
(Doc. #8) 

Reproduced 
from Doc. #7 

Testers 

SQA Rep. 

Support /Development 
System Configuration 
(Doc. #9) 

Doc 

Mgmt. Team 

SQA Rep. 

Accomplishment 
Summary 
(Doc. #10) 

Doc 

Mgmt. Team 

SQA Rep. 
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Table 1: Organization and Authorization for Managed Documents (cont.) 


Document 

Library 



Authorized 

Requesters 

Authorized 

Controllers 

Verification/ 
Validation Plan 
(Doc. #11) 

Doc 

Mgmt. Team 
Testers 

NASA Rep. 
Cfg. Mgr. 

Test Cases/Runs 
(part of Doc. #11) 

Test 

Testers 

NASA Rep. 
Cfg. Mgr. 

Design Standards 
(Doc. #12, included 
in Doc. #4) 

Doc 

Mgmt. Team 

SQA Rep. 

System Requirements 
(Doc. #13) 

Doc 

Mgmt. Team 

SQA Rep. 

Certification 
Document 
(Doc. #14) 

Doc 

Mgmt. Team 

SQA Rep. 
Cfg. Mgr. 

Problem Reports 

Hard Copy 

Testers 

SQA Rep. 
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3 Configuration Procedures 

All documents under configuration control will be located in their libraries, 
or in binders held by the controller, and after they are put under con- 
trol, only the authorized controllers may update the library by reserving, 
replacing, adding, or deleting elements within the library. EXTREME 
PRUDENCE should be used when deleting elements from libraries. All 
authorized requesters should be made aware of the locations of the libraries, 
and will be allowed to fetch files from these libraries. By fetching files, no 
changes are made to the library, thus the integrity of the experiment is 
maintained. VMS access control allows CMS libraries to be set up so that 
some people may fetch files from a given library without being able to re- 
serve, replace, add, or delete files. In addition, backups are made every 
twelve hours of files that have been modified or changed, and once each 
month, all files are backed up onto tape media. 

Anyone desiring access to files under configuration control should ask 
one of the authorized requesters for the files they need. If no changes are 
anticipated, the requester may fetch the files. If changes are anticipated, 
the requester should send an electronic request to the controller who will 
then reserve the files and send them to the person asking for them. 

It is the job of the requester and the controller to insure that all trans- 
actions in the CMS library are documented using the built-in commenting 
ability of CMS. The requester and the controller have the right to refuse 
access to files or to require further documented justification for file access. 
If the controller sees fit to do so, each document request may be placed into 
the libraries for later reference. 

4 Version Numbering Scheme 

When each document is placed under configuration management, it will be 
considered version 1.0 of that document. After that time, any modifications 
to the document will increment the counter to 1.1, 1.2, ... For documents, 
such as the design description, which require hard copy output, only the 
sheets that have been modified should be printed and configured. At major 
milestones, the version number will be incremented to 2.0, 3.0, . . . and hard 
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copy documents will be completely re-printed. Each version of a document 
will be organized as a CMS “class” for ease in later retrieval of versions. For 
documents that require separate versions for each programmer (e.g. design 
documents, source code, etc. ) the programmer’s identification name will 
be added to the beginning of the version number. For example, the first 
revision of Jupiter’s design document would be: Jupiterl.l. Following is 
a list of documents under configuration management and a milestone that 
will determine when they are put under configuration control: 

Configuration Index (Doc #1) After SQA approval. 

GCS Specification (Doc #2) When Venus and Jupiter start Prototypes. 

Specification Modifications After SQA approval. 

Design Description (Doc #3) After Design Review. 

Programmers’ Manual (Doc #4) After SQA approval. 

Programmer Instructions After SQA approval. 

Configuration Management Plan (Doc #5A) After SQA approval. 

Software Quality Assurance Plan (Doc #5B) After Mgmt. Team ap- 
proval. 

Programmers’ Source Listing/Code (Doc #6/#7) At first clean com- 
pile. 

Object Code (Doc #8) At first clean compile. 

System Configuration (Doc #9) After SQA approval. 

Accomplishment Summary (Doc #10) End of project after SQA ap- 
proval. 

Verification / Validation Plan (Doc #11) After SQA approval. 

Test Cases / Runs As test case is generated. 

Design Standards (Doc #12) After SQA approval. 
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System Requirements (Doc #13) After SQA approval. 

Certification Document (Doc #14) After SQA approval. 

Problem Reports When a problem is first reported, a problem report 
will be completed according to the procedures listed in the SQA Plan. 

For example, the major milestones for changing version numbers of the 
code will be: 

• Clean compile (1.0), 

• Code review (2.0), 

• End of Module Testing (3.0), 

• End of White Box Sub-Frame Testing (W3.x), 

• End of Black Box Sub-Frame Testing (B3.x), 

• End of Sub-Frame Testing (4.0), 

• End of Frame Testing (5.0), and 

• End of System Testing (6.0). 
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A Representatives 

Following are the abbreviations used in this document along with the people 

they represent: 

Cfg. Mgr. Configuration Manager - B. Edward Withers 

Doc. DO-178A Document 

Mgmt. Team Management Team - Leslie Dent, Stephen Duncan, Janet 
Dunham, Douglas S. Lowman, Anita Shagnea, and B. Edward With- 
ers. 

NASA Rep. NASA Representative - Kelly Hayhurst. 

SQA Rep. On-site Software Quality Assurance Representative - Stephen 
Duncan 

Testers GCS Testers - Leslie Dent, Anita Shagnea, and Charlotte Scheper 
User GCS User - B. Edward Withers 

Requester Individual responsible for documenting any changes made to 
documents and who may fetch a copy for working purposes or request 
that a copy be reserved for updating. 

Controller Individual responsible for assuring that all changes have been 
documented, and who has the power to reserve and replace docu- 
ments. This individual may refuse to allow changes to propogate to 
the official versions until appropriate documentation has been com- 
pleted. 


- 8 - 



References 


[1] George B. Finelli. Results of software error-data experiments. In 
AIAA/AHS/ASEE Aircraft Design, Systems and Operations Confer- 
ence, Atlanta, GA, September 1988. 


- 9 - 


NASA 

Naronai Aponauics ana 
Srvice ^n^st'aton 


1. Report No. 

' NASA CR- 182044 


4. Title and Subtitle 


Report Documentation Page 


2. Government Accession No. 


GCS Configuration Management Plan 


3. Recipient’s Catalog No. 

5. Report Date 

May 1990 

6. Performing Organization Code 


7. Author(s) 


B. Edward Withers 


9. Performing Organization Name and Address 
Research Triangle Institute 
P.0, Box 12194 

Research Triangle Park, NC 27709-2194 

12. Sponsoring Agency Name and Address 

National Aeronautics and Space Administration 
Langley Research Center 
Hampton, VA 23665-5225 


8. Performing Organization Report No. 


10. Work Unit No. 

505-66-21-01 

11. Contract or Grant No. 

NASl-17964 

13. Type of Report and Period Covered 

Contractor Report 

14. Sponsoring Agency Code 


15. Supplementary Notes 

Technical Monitor: George B. Finelli , Langley Research Center 

Task 8 Report 


16. Abstract 

This document describes the tools and methods used for the configuration management of the 
artifacts (Including software and documentation) associated with the Guidance and Control Software 
(GCS) project. The GCS project Is part of a software error studies research program conducted by the 
Research Triangle Institute and the NASA Langley Research Center. For this project, three 
implementations of GCS are being produced according to the Radio Technical Commission for 
Aeronautics RTCA/DO-178A guidelines. "Software Considerations in Airborne Systems and 
Equipment Certification" in order to study the fundamental characteristics of the software failure 
process. The Code Management System (CMS) provided by Digital Equipment Corporation is used to 
track and retrieve versions of the documentation and software. This document describes the 
application of the CMS for this project and delineates the numbering scheme for the versions of the 
project artifacts. This document fulfills the requirements for document #5B in the KTCA/DO-178A 
guidelines. 



17. Key Words (Suggested by Author(sl) 

Configuration Management 
Guidance and Control Software (GCS) 
Configuration Control 

18. Distribution Statement 

Unclassified-Unlimited 
Subject Category 61 


19. Security Classif. (of this report) 

20. Security Classif, (of this page) 

21. No. of pages 

22. Price 

Unclassified 

Unclassified 


13 

A0 3 


NASA FORM 1626 OCT 86 









